fixes: #1964

The SQL syntax crash does not seem to occur as an empty array produces = ANY ('{}') which is valid SQL. A test asserting store returns Seq.empty for an empty input was added as a regression test in case inClause semantics change.

This PR instead addresses the user-facing concern: calling /v0/validators/validator-faucets with no validator_ids (or a misspelled key like validator=) used to return 200 + empty list, masking the typo. It now returns HTTP 400 with a clear error.

@JYC11 I'm confused by this statement:

The SQL syntax crash does not seem to occur

The issue says that it does occur. Did you try reproducing the issue?

Seems like you're right, and the sql error has already been fixed.

$ curl https://scan.sv-1.dev.global.canton.network.sync.global/api/scan/v0/validators/validator-faucets?validator_ids=foo::bar
{"validatorsReceivedFaucets":[]}

Given that the issue is almost a year old, that's not too surprising.
Your PR covers only a very specific case of the validator IDs list truly being empty, not the case where they're all invalid (as above).
Having said that, given that liveness rewards have been removed from the network months ago, I don't think we want to invest in the UX of this endpoint TBH. I'd suggest we just close the issue and this PR.

Seems like you're right, and the sql error has already been fixed.

$ curl https://scan.sv-1.dev.global.canton.network.sync.global/api/scan/v0/validators/validator-faucets?validator_ids=foo::bar
{"validatorsReceivedFaucets":[]}

Given that the issue is almost a year old, that's not too surprising. Your PR covers only a very specific case of the validator IDs list truly being empty, not the case where they're all invalid (as above). Having said that, given that liveness rewards have been removed from the network months ago, I don't think we want to invest in the UX of this endpoint TBH. I'd suggest we just close the issue and this PR.

That's fine by me, I'll close the PR. Can you close the issue?